For several years remote control devices have been common in the consumer electronics industry. These devices include controllers for televisions, radios and multimedia computers. Moreover, remote control capabilities have recently been extended to “smart” versions of more traditional products such as refrigerators, washers, dryers, garage door openers, lawn irrigation systems and climate controls. Given their popularity, it is quite clear that the number of products with remote control capabilities will only increase. Furthermore, as new features are added to these products, the complexity of the remote control capabilities and features for these products will also increase.
A one-to-one relationship predominates between products and their remote control devices. Generally, the remote control devices are designed specifically for the product for which they were manufactured. As a result, there is little uniformity in the features offered by manufacturers even for the same type of product. Furthermore, there is little interoperability between manufacturers' software used to program the remote control devices due to the fact that, in many cases, each manufacturer utilizes proprietary software.
Thus, the current situation has led to a world in which the typical household contains numerous remote control devices, not only to control several different products, but many of which to perform the same task for the different products or even for the same type of product. For example, an on/off switch is included for nearly every remote control situation, but oftentimes a different on/off switch is required for each television, radio, light fixture, and so on. Even products made by the same manufacturer may contain different software and thus, remote control devices that are not compatible. As such, a household will typically have as many remote control devices as products to control. In an increasingly remotely driven future, the situation will become even more difficult and confusing for average consumers, many of whom can barely keep up with the clutter today.
There have been limited attempts to improve this less than optimal situation. Various “universal” remote control devices are commercially available, particularly in the consumer electronics industry. These remote control devices allow for some degree of uniformity when controlling similar or complimentary devices, such as, for example, televisions, A/V receivers, DVD players and the like in a home theater system. However, universal remote controls usually require a time consuming programming or “learning” phase in order to “teach” the remote control device how to control the various products. As can be expected, the process is often complicated and usually requires involvement well beyond the expectations of the average consumer. Further, the capabilities of each of the individual remote control devices are often so specialized and manufacturer-specific that, although the universal remote control device may be able to learn the more basic features, other remote control features that are unique and/or proprietary will still require the use of the OEM remote control device. Therefore, the universal remote control device does not provide a solution to the proliferation of remote control devices in most situations. In fact, a universal remote control device may further confuse the situation by creating ambiguities as to which remote control device can perform a specific function for a particular product. As such, the universal remote control device has so far only been able to provide a limited solution for remote control clutter in a rather narrow consumer product area.
There have also been attempts by various manufacturers to provide broader home and/or commercial building automation systems. For the most part, these attempts have been either very expensive, very rudimentary, or both. For example, many of these automation systems have been slow, unreliable and lacking in security because, for the most part, no uniform standard for compatibility has been established on an industry-wide scale. As such, the home/commercial building automation industry remains a collection of niche markets for either the very technically inclined and/or the very wealthy. To change this collection of niche markets into a single market large enough to achieve economies of scale suitable for mass production, a standard communication protocol, suitable for many or most sensing and actuating applications, is needed. Such a protocol must be flexible enough to meet the needs of the individual applications, while still remaining economically viable.
Recently, various wireless communication standards with capabilities beyond the traditional infrared-based remote control device have become available for a variety of applications, most notably broadband Internet access. For instance, the recent development of the Wi-Fi™ wireless local area network (WLAN) communication standards, IEEE 802.11(a)(b)(g), has vastly increased the capabilities of the notebook computers though the use of standardized medium range wireless routers. Wi-Fi™ is tailored toward high data rate Internet and local area networking and is useful for some home automation applications, particularly the control of more complex products such as multimedia computers and security cameras that require large data throughput rates.
Another recent wireless technology standard is Bluetooth®. Bluetooth® is a short range wireless personal area network (WPAN) standard, IEEE 802.15.1, that has uses for cable replacement and product interoperability in a close range environment, such as between a cellular telephone and an automobile hands-free speaker system. However, Bluetooth® networks have a limited range: They may have at most eight devices, with limited power output, and Bluetooth® has no standardized mechanism for relaying transmitted packets from source to destination by multiple intermediate devices (so-called “multi-hop routing”). This range limitation limits the utility of Bluetooth® in many applications, from consumer electronics to appliances, sensors and actuators, that may exist in a typical home or building automation system.
The performance metrics valued in a personal area network designed to meet the requirements of sensing and actuating applications are separate from those valued in Wi-Fi™, Bluetooth® and the like. For example, those standards typically value data throughput rates and channel efficiencies (i.e., the number of information bits per second transmitted per Hertz of occupied frequency spectrum) above other metrics such as power consumption and implementation cost. For example, typical Wi-Fi™ implementations can consume more than 100 milliwatts of power and are required to store a protocol stack that is 100 kilobytes (KB) or more in size, a requirement that places a lower bound on the implementation cost of the device. However, the power and memory necessary to achieve high data throughput rates and high channel efficiencies such as for Wi-Fi™ applications, is not necessarily so critical for sensing and actuating applications. Instead, network devices in sensing and actuating applications are more likely to require long battery life (low power consumption) and low cost. Since these networks may consist of tens to perhaps thousands of devices, and may be attached to very inexpensive sensors and actuators, to be economically viable it is important that the devices themselves be extremely inexpensive and that battery replacement be as infrequent as possible. Should power consumption reach low enough levels, it is possible in some applications for devices to scavenge energy directly from their environment (via sunlight, vibration, or other means), eliminating the need for batteries entirely and greatly enhancing the practicality and economic viability of the network.
More specifically, a personal area network designed for sensor and actuator applications may consist of three generalized device types. The first device type is a network coordinator which maintains overall network knowledge such as the network identification. This device will require the most memory and computing capabilities and, for large networks, may have the same memory capabilities as devices common to Wi-Fi™, Bluetooth® or other radio communication networks.
A second device type is the “fully functional” device. The fully functional device is the most flexible device type because it can function as a limited network coordinator or as an end device at points where the network interacts with the real world (e.g., a user interface). For example, a garage door opener remote control device may be a fully functional device. A key function of the fully functional device is that, like the network coordinator, it can relay messages intended for other devices in the network.
The final general device type is the “reduced function” device. This type of device is extremely low cost because it carries limited memory and computing power. It is an end device such as a window sensor in a security system. The main priority for a reduced function device is to conserve power until a trigger event occurs.
Most of the data that flows between devices in a network primarily consisting of sensors (i.e., lighting, security systems) and actuators (i.e., remote control devices, building control systems) consists of small packets that either periodically control a particular device or group of devices or obtain status information from a device or group of devices. For the most part, the status information generally consists of querying whether the device or group of devices is on or off. For example, a smoke detector or a window contact in a security system will only send information on the network when a trigger event occurs, (e.g., when smoke has been detected or the contact has been broken), or when the operational status of the device is requested. Thus, for the vast majority of the time, these devices operate under minimal power to maintain their reliability, which essentially means staying in a “deep sleep” mode to not run out of battery power before a trigger event occurs.
An automation network should be designed to support various traffic topologies including local any-point to any-point communication, data gathering from a large network and control of a large network from a single or a few points. For example, local any-point to any-point communication may be useful in applications such as lighting control, entertainment system control (e.g., television, DVD player, A/V receiver, cable/satellite receiver, etc.), home and building automation, office/commercial control, human interface devices, home security, HVAC systems and the like. Data gathering from a large network may include environmental monitoring, security sensing, building automation and monitoring, military sensing, office/commercial control, structural monitoring, equipment monitoring, amusement park automation, utility metering, large area sensing and precision agriculture. The control of a large network by a single or a few points may include various building automation and office control functions. As one might expect, many applications may require a combination of network traffic topologies.
Another aspect of an automation network is that the devices, particularly remote control devices, may be mobile within or at the edges of the network area. A typical household area of operation is about 30-70 meters and perhaps more for building control operations and remote sensing applications. Therefore, the network has to be able to accommodate flexible network configurations such, as for example, star, mesh or hybrid network configurations. In addition, networks may consist of devices from many different manufacturers, having varying features and differing amounts of memory.
The need to support a wide variety of applications, with a wide variety of network configurations, implies that the algorithm used to route packets in the network must also be flexible. Many existing algorithms, such as the ad hoc on-demand distance vector (AODV) routing protocol developed by the Mobile Ad Hoc Networking Working Group of the Internet Engineering Task Force (http://www.ietf.org/internet-drafts/draft-ietf-manet-aodv-13.txt), require the use of a “route table” to store route information to each destination device. However, for personal area networks designed for sensor and actuator applications the cost of the memory needed for this table becomes excessive for even moderately-sized networks. In addition, the latency associated with first discovering the route can adversely affect the network user experience. For example, a discernable delay between the time a newly-purchased wireless light switch is used and the time the light comes on, may lead the inexperienced user to believe his switch is faulty. Other existing algorithms, such as the tree-based algorithm described in U.S. Pat. Appl. No. 2003/0227931 to Chen et al., do not employ route tables, but find routes that are not necessarily the shortest available, thereby unnecessarily delaying packet delivery and again negatively affecting the user experience.
What is needed is a communications system that accommodates devices of varying capabilities, from coordinator devices to reduced function devices that have very low power requirements and limited memory capabilities. The communication system needs to exhibit flexibility to accommodate additional devices as they come within range of the network, but with better communication reliability than what is presently available. Further, the communication system needs to exhibit flexibility to satisfactorily accommodate a wide variety of potential applications, each with differing requirements for message latency, network size, and device cost. In addition, a need exists for a communication system capable of routing data by taking advantage of the network topology and the varying capabilities of the network devices.